Methods and apparatuses for programming user-defined information into electronic devices

ABSTRACT

A device for programming user-defined information into an electronic device is provided. The programmer allows a user to program customized information, such as user-selected audio, video, or Internet access information into his or her programmable device. Such electronic devices include wireless telephones, pagers, and personal digital assistants. The programmer allows a user to, among other things, customize the device to suit his or her particular taste.

CROSS-REFERENCE TO RELATED APPLICATIONS

This application is a continuation of U.S. patent application Ser No.12/128,991, filed May 29, 2008, which is a continuation of U.S. patentapplication Ser. No. 11/633,142, filed Dec. 2, 2006, now U.S. Pat. No.7,555,317, which is a continuation of U.S. patent application Ser. No.10/600,975, filed on Jun. 20, 2003, now U.S. Pat. No. 7,149,509, whichis a continuation of U.S. patent application Ser. No. 09/518,846, filedMar. 3, 2000, now abandoned, which claims priority from U.S. ProvisionalPatent Application No. 60/169,158, filed Dec. 6, 1999, the entiredisclosures of which are expressly incorporated herein by reference.

BACKGROUND OF THE INVENTION

1. Field of the Invention

This application relates to electronic devices, and more particularly toa programming apparatus that allows users to program user-definedinformation into their electronic device.

2. Related Art

There are many types of electronic devices available to consumers todaythat have the ability to produce both audio sounds and video displays.Many of these devices provide users with the ability to select and playa particular piece of audio or video. A television viewer, for example,may tune to a TV channel and watch a particular program, or connect aVCR or DVD player to the television in order to view a specific programnot currently being broadcast. Similarly, an audio system user may tunea receiver to a particular radio station to hear a certain genre ofmusic, or connect a CD or tape player to the system in order to hearspecific pieces of music. In both cases, the audio and video isuser-selectable.

Currently, however, there are many electronic products that offer anaudio/video playing capability that are not fully user-programmable.Users of such devices (e.g., wireless or cordless telephones, pagers,personal digital assistants (PDAs), hand-held computers and the like)have to choose from a limited selection of pre-programmed information(e.g., audio clips, video clips or frames, etc.) placed there by themanufacturer. This severely limits the user's ability to customize thedevice to suit his or her particular taste. Furthermore, mostpre-programmed audio tends to be rather generic and can be confusingwhen a device of a nearby user generates a sound similar to or the sameas that of another user's device. Although a programmable memory withinmany such electronic devices could support user-defined audio,currently, no system exists for programming such information into anelectronic device.

The same is true for user-defined video. For example, certain types ofuser-defined video information, such as video clips, frames, and otherdigital or analog images could be programmed into an electronic device(e.g., PDA, wireless phone, or any portable display device) anddisplayed at a time of the user choosing. Although a programmable memorywithin such a device could support user-defined video, currently, nosystem exists for programming such information into the device.

SUMMARY OF THE INVENTION

It is therefore an object of the present invention to provide anapparatus that allows a user to program user-defined audio informationinto a programmable electronic device.

It is a further object of the present invention to provide an apparatusthat allows a user to program user-defined video information into aprogrammable electronic device.

These and other objects of the present invention are accomplished byproviding methods apparatuses that allow a user to program user-definedinformation into his or her electronic device. In one embodiment of thepresent invention, the programming apparatus includes processingcircuitry and first and second communications links. In operation, auser selects a piece of information from a source such as a computerdisk drive, the Internet, or a remote database using the firstcommunications link. The programming apparatus may download thisinformation and compare its format with that required by theprogrammable device to determine format compatibility. If the twoformats are compatible, the programming apparatus may download theselected information into the programmable device. If the formats arenot compatible, the programming apparatus may convert the downloadedfile to a format compatible with that required by the programmableelectronic device. The programming apparatus may also provide the userwith an opportunity to edit the converted file. Once editing iscomplete, the resulting file may then be programmed into theprogrammable device for subsequent use.

In another aspect of the invention, a user may send customizedinformation such as an audio or video file called a “signature” whenplacing a telephone call This feature allows a user to select and send asignature file to the person receiving the telephone call such that theperson receiving the call is alerted by that file.

BRIEF DESCRIPTION OF THE DRAWINGS

The above and other objects and advantages of the present invention willbe apparent upon consideration of the following detailed description,taken in conjunction with the accompanying drawings, in which likereference characters refer to like parts throughout, and in which:

FIG. 1 is a generalized block diagram of a system for programminguser-defined information into an electronic device in accordance withone embodiment of the present invention.

FIG. 2 is a schematic diagram of a programmer constructed in accordancewith one possible embodiment of the present invention.

FIG. 3 shows a computer based implementation of a programmer constructedin accordance with one embodiment of the present invention.

FIG. 4 a shows an alternate embodiment of a computer basedimplementation of a programmer constructed in accordance with theprinciples of the present invention.

FIG. 4 b shows an alternate network embodiment of the computer basedimplementation in shown in FIG. 4 a.

FIG. 5 illustrates an imbedded implementation of the programmer shown inFIG. 2.

FIG. 6 shows yet another embodiment of a computer based implementationthe programmer in shown in FIG. 4 b.

FIG. 7 is a schematic diagram of one possible embodiment of a wirelesstelephone that can receive and play user-defined audio in accordancewith one aspect of the present invention.

FIGS. 8-9 show a flow chart illustrating some of the steps involved inprogramming user-defined information into an electronic device inaccordance with one embodiment of the present invention.

FIGS. 10-12 show a flow chart illustrating some of the steps involved insending and receiving signature information in accordance with oneembodiment of the present invention.

DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENT

FIG. 1 shows a block diagram of a system 10 for programming user-definedinformation (e.g., audio, video, or Internet access information, etc.)into an electronic device in accordance with one embodiment of thepresent invention. As shown in FIG. 1, system 10 generally includes aprogrammable electronic device 20, a device programmer 30, and a source50. Programmer 30 is connected to source 50 via link 31, and to device20 via link 32.

Programmable device 20 may be any portable electronic device (e.g., awireless telephone, a pager, a handheld computer, personal digitalassistant (PDA), etc.). Device 20 may also be any device whichintegrates some or all of the functions of such devices into one device.For example, device 20 may be a PDA capable of making wireless telephonecalls, a PDA with paging functions, a wireless telephone with some PDAor paging functions, a handheld or notebook computer with some or all ofthe functions of a PDA, a pager, and a telephone, etc.

In FIG. 1, links 31 and 32 may be, for example, communications links(e.g., serial ports, parallel ports, universal serial buses (USB),RS232, GPIB, etc.), modems (e.g., any suitable analog or digital modems,cellular modems, or cable modems), a network interface link (e.g.,Ethernet links, token ring links, etc.), wireless communications links(e.g., cellular telephone links, wireless Internet links, infraredlinks, etc.), or any other suitable hard-wired or wireless Internet orcommunications links.

Source 50 may be any device or combination of devices suitable forproviding user-defined information to programmer 30 (e.g., the Internet,an optical disc player (CD, DVD), a cassette player, a VCR, a digitalcamera, or any suitable storage device containing computer programs orfiles, etc.).

In operation, a user may choose certain information, such as Internetconfiguration information, an audio sample of a popular song, a videoclip or frame, etc., that is available from source 50 and transfer it toprogrammer 30. Programmer 30 may then process this information into asuitable format (or may simply route the information if no formatconversion is required), and program it into a programmable memorywithin device 20 (not shown). Device 20 may then retrieve thisinformation when a certain event occurs (e.g., when receiving anincoming telephone call, browsing the Internet, or when programmed to doso by a user, etc.).

Programmer 30 may also coordinate or perform certain functions relatedto the routing and storing of information within device 20. For example,programmer 30 may communicate with (or simply search) device 20 to findavailable memory locations in which to store the user-definedinformation. Programmer 30 may also communicate with device 20 todetermine which format the incoming information should be converted toso that the information is compatible with the downloading requirementsof device 20. For audio files, this may include, but is not limited to,converting to or from any of the following format types: analog; MIDI;MPEG; PCM; Windows Media Audio Code (WMA); WAV; or Adaptive TransformAcoustic Coding (ATRAC), or to or from any other suitable audio format,etc. For video files, this may include, but is not limited to,converting to or from any of the following format types: analog; JPEG;MPEG; GIF; AVI, or to or from any other suitable video format, etc. Textfiles may include, for example, HTML files, Wireless Markup Language(WML) files, WordPerfect™ files, Microsoft Office™ files, or any othersuitable text files.

If multiple blocks of information are being programmed into device 20,programmer 30 may “tag” the different blocks so that device 20 and/or auser may distinguish among the different blocks stored therein. Afterthe information has been provided, programmer 30 may communicate withdevice 20 to confirm that the information has been correctly received.

A more detailed diagram of one possible embodiment of programmer 30 isillustrated in FIG. 2. As illustrated, programmer 30 may include atransducer 25, a processor 34, a programmable memory 36, ananalog-to-digital (ND) converter 38, signal processing circuitry (SPC)40, an output buffer 42, and an input buffer 44. Generally speaking,processor 40 controls the operation of programmer 30. Programmer 30 maybe configured to receive and process both analog and digital signals. Itmay also acquire acoustic signals via transducer 25 (if installed).

In operation, programmer 30 may download certain user-selectedinformation from source 50 via link 31. This information, such as audioor video files, in the form of electronic signals, may be received fromlink 31 and directed to input buffer 44. As mentioned above, thesesignals may need to be processed in order to be compatible with theformat required by programmable device 20. For example, if analog inputsignals are received at input buffer 44 and device 20 requires a digitalformat, the analog signals may be routed to ND converter 38 forconversion into a suitable digital form (e.g., into PCM, PAM, etc.).Further processing into another digital format (e.g., MP3, ATRAC, WMA,etc.) may be accomplished by routing the converted signals to SPC 40 orprocessor 34 (discussed in more detail below). On the other hand, ifdigital input signals are received at input buffer 44 and device 20requires analog signals, the digital signals may be routed to SPC 40 orto a dedicated digital-to-analog (D/A) converter (not shown) forconversion to the analog domain.

Processor 34 may route incoming signals from source 50 to memory 36, SPC40, or directly to output buffer 42 depending on the circumstances. Forexample, some or all of the input signals received from source 50 mayrequire further processing to meet the downloading specifications ofdevice 20. In this case, the incoming signals that require processingmay be routed to SPC 40 for such processing. For example, incoming MP3or WMA signals may be routed to SPC 40 and converted to ATRAC format (orvice-versa). Once this conversion is complete, the resulting informationmay be stored in memory 36, or routed to output buffer 42 forprogramming in device 20. Input signals that do not require a formatchange may be routed directly from input buffer 44 to memory 36, oroutput buffer 42. Although not shown in FIG. 2, programmer 30 preferablyhas a display screen and a data input device, such as a keyboardassociated with it so that a user may, among other things, browse andselect files, monitor file transfers, and ensure that device 20 hasproperly received the selected files.

In one embodiment of the present invention, SPC 40 may be programmableso that the conversion and processing protocols contained therein may beperiodically updated. Furthermore, in some embodiments, processor 34 maybe programmed via software routines in programmable memory 36 to performsome or all of the functions of SPC 40. In this case, an SPC of reducedprocessing capacity may be used or SPC 40 may be removed altogether fromprogrammer 30.

Audio signals may also be acquired and processed by programmer 30.Transducer 25 may acquire an acoustic signal from a stereo or otheraudio source and convert it to an electrical signal. This electricalsignal may then be processed in a way similar to the way theabove-described analog signal was processed. That is, the electricalsignal may be routed to A/D converter 38 and/or SPC 40 and then storedin memory 36 or output buffer 42, for example.

It will be understood that the generalized system shown in FIG. 1 may beimplemented in many ways. For example, as shown in FIG. 3, system 100may be implemented using a computer-based architecture. In this case,some or all of programmer 30 may be installed in or connected to acomputer, such as a personal computer. For example, in FIG. 3,programmer 30 may be installed in an expansion slot and connected to aninterface bus such as an ISA or PCI bus (not shown) in computer 60. Inthis configuration, programmer 30 may receive user-defined informationvia the interface bus in computer 60 and operate as described above withthe interface bus acting as part of link 31. Some or all of programmer30 may also be external to computer 60 and connected to it via a linksimilar to link 31 (not shown). Furthermore, in certain embodiments,some of the functions of programmer 30 may be distributed betweencomputer 60 and programmer 30. For example, programmer 30 may beconstructed such that it partially or fully relies on the processingcapability of computer 60. In this type of embodiment, programmer 30 maybe constructed without processor 34 or with a processor of reducedcapacity. Programmer 30 may also be constructed such that it partiallyor fully relies on the memory capacity of computer 60. Moreover, signalprocessing functions such as those performed by SPC 40 could also befully or partially carried out by circuitry or software resident withincomputer 60.

As shown in FIG. 3, computer 60 may be connected to Internet 80 throughlink 70. Link 70 may be, for example, a modem (e.g., any suitable analogor digital modem, cellular modem, or cable modem), a network interfacelink (e.g., an Ethernet link, token ring link, etc.), a wirelesscommunications link (e.g., a wireless telephone link, a wirelessInternet link, an infrared link, etc.), or any other suitable hard-wiredor wireless communications link. With this configuration, a user maydownload information from Internet 80 (e.g., using electronicdistribution (ED) services) and/or from a disc drive or other devices(not shown) connected to computer 60 and program that information intodevice 20 (via programmer 30 and link 32).

It will be understood, of course, that computer 60, with a suitablecommunications link, such as link 32, may be programmed with software tofunction as programmer 30. In this way, a user may take advantage of thefact that many of the components of programmer 30 are resident withincomputer 60. For example, computer 60 may contain a processor, such asprocessor 34 and programmable memory circuitry such as memory 36.Computer 60 may also include signal processing circuitry such as SPC 40,or software that instructs processor 34 to perform the necessary formatconversions. Computer 60 may include circuitry similar to input buffer44 and output buffer 42. Such circuitry may include random access memory(RAM) or cache memory in computer 60. Computer 60 also may includeinternal or external AID conversion circuitry, such as A/D converter 38,and an internal or external transducer 25.

As shown in FIG. 4 a, computer 60, programmed to function as programmer30, may be connected to Internet 80 through link 70 and to device 20through link 32. This arrangement allows a user to select informationfrom Internet 80 or from a storage device connected to computer 30 (notshown) for programming into device 20.

Using the generalized system shown in FIG. 4 a, user-defined informationmay be programmed into device 20 in many ways. For example, computer 60may be part of a communications network 95, such as a telephone network,that provides Internet and/or telephone access to programmable device 20(shown in FIG. 4 b). Communications network 95 may be provide hard-wiredor wireless telephone or Internet access (or combination of the two).This arrangement is generally illustrated in FIG. 4 b as architecture200, in which computer 90, for the sake of clarity, represents computer60, configured at least in part, to function as programmer 30.

With this configuration, a user of device 20 may access Internet 80 andselect information for downloading into device 20. It will beunderstood, however, that in this implementation, at least a portion ofcomputer 90 is configured to function as programmer 30, and thatcomputer 90 may continue to perform other functions such ascommunicating with network computers 82, communicating with Internet 80,interfacing with external telephone network 84, and coordinatingwireless Internet and telephone access etc., in addition to performingsome or all of the above-described programming functions.

In operation, computer 90 may communicate with device 20 to determineits format requirements and perform any conversions necessary to makeuser-selected information compatible with those requirements. Thisallows a user to select information, such as audio and/or video, that isavailable on the Internet or on a remote network computer, and programthat information into device 20. This may be accomplished viacommunications link 33 (which may be any type of link previouslydescribed as suitable for link 32). For example, a user may wish todownload video images from an Internet site to a hand-held computer,such as a PDA, or to a wireless telephone. The user may communicate withcomputer 90 via a wireless link 33 and select information from Internet80 using an Internet browser installed in device 20. Such a browser maybe a Wireless Application Protocol (WAP) compliant browser forsupporting wireless Internet services. Computer 90 ensures formatcompatibility of the information, transmits the information to device20, and may communicate with device 20 to confirm that the selectedinformation has been properly received. Device 20 may provide a visual,audio, or tactile output to indicate the requested information has beensuccessfully received.

Computer 90 may also coordinate information downloading with respect tothe memory capacity of device 20. For example, if the user-selectedinformation exceeds the available memory of device 20, computer 90 mayinform the user, via link 33, that the selected information is largerthan the available memory. In such an event, the user may be prompted tocancel or modify the information request. In certain instances, however,the user may instruct computer 90 to provide the information in a“scrolling” fashion (i.e., provide it in portions) so that all therequested information may be reviewed, albeit in sections. This may beparticularly desirable in instances where large files, such as videofiles, are requested.

In some embodiments of the present invention, computer 90 may simplycontact a remote computer or Internet site to fulfill requests for audioor video information in a particular format. Such web sites or remotecomputers may act as virtual “jukeboxes” of video and audio information,containing extensive lists of such information in a variety of formatsavailable for downloading. Using this approach, a user may select aparticular piece of information in a certain format from a listdisplayed on a screen of programmable device 20. Computer 90 may receivethis as a request via link 33 and handle the information transfer todevice 20. In some embodiments, format selection may be transparent tothe user. That is, the user may simply request a piece of informationand computer 90 may determine and then request information in a formatappropriate for the requesting device.

In another embodiment, a remote computer or Internet site may perform aformat conversion of information requested by computer 90 or device 20.For example, a user may access an Internet site or remote computer usingcommunications network 95 and enter a title or description of thedesired audio or video information along with format requirements. Theremote computer or Internet site may then search the Internet or otherdatabases to find a file that matches the user's description. Once thisfile is found, the Internet site or remote computer may convert thatfile to the requested format, (using a system similar to the describedabove) and provide it to device 20 via computer 90 and/or link 33. Itwill be understood, of course, that embodiments such as these are withinthe scope of the present invention.

If desired, a user may also employ the systems shown in FIGS. 4 a and 4b to download remotely stored information such as Internet accessinformation to device 20. For example, a user may have customizedbookmarks or web page addresses stored in a remote personal computer oron Internet 80. The user may employ wireless link 32 or 33 to contactthat remote computer or Internet site and then download the Internetaccess information for use in device 20. This feature is desirablebecause it relieves the user of the burden of having to type incomplicated Internet access information from the small keyboard of awireless telephone or hand-held computer. It also spares the user fromhaving to re-enter customized Internet information that is alreadypresent in another location, into their electronic device. Moreover,such a feature is convenient when a user wishes to access information ona remote computer that is not currently available in device 20. Forexample, a user may wish to view spreadsheet information stored on aremote computer with device 20. Rather than having to download thisinformation form a hard-wired access point, a user may simply employwireless link 33 (e.g., a wireless modem or Internet connection) toaccess that remote computer or Internet site and download thatinformation to device 20.

Another feature which may be implemented using the embodiments shown inFIGS. 4 a and 4 b is a “signature” feature. This allows device 20 tosend user-defined information, which may be indicative of the user'spersonal taste or identity, along with other information when performingcertain functions. For example, if a user is placing a wirelesstelephone call or paging someone with device 20, he or she may selectthe signature feature in order to send user-defined audio or video alongwith, or prior to, that call. A user may accomplish this by browsingthrough a menu on device 20 that displays available signature options,and by choosing a particular file (not shown). If the user chooses anaudio file, for example, device 20 may send that selected audio filewhen a call or page is placed (or a period of time before the call orpage is placed). This audio file may temporarily replace the “ringsequence” of the device receiving the incoming call so that the personreceiving the incoming call will be alerted by hearing the audio filesent by the caller. The person receiving the call may be able to discernthe identity of the caller or other information from the audio file.After the call is complete, the ring sequence of the receiving devicemay be returned to its former configuration (either by computer 60 or bythe receiving device).

In another embodiment, a user may program certain audio or video filesinto device 20 that are activated when a certain person calls. Forexample, a user may program device 20 so that certain signature filesare played in response to receiving a characteristic indicative of thecaller, such as the caller's telephone number. In this way, a user willbe able to identify the caller by the sound and/or display generated bydevice 20. Users may also program signatures in device 20 to be playedat predetermined times. For example, a user (or caller) may program“Happy Birthday” or “Jingle Bells” into device 20 to play on a certainday, or may program device 20 to play a certain signature file atspecified time (e.g., as an alarm).

In yet another embodiment, a user, when placing a call, may invoke amenu on device 20, which displays a list of signature files availablefor the person being called. This list may be defined by the personreceiving the call. For example, the person receiving the call maycreate a signature file list by selecting certain audio and/or videofiles and placing them in a database of a remote computer such ascomputer 90 by using, for example, a personal computer connected to theInternet. In some embodiments, signature files may also be stored in adevice 20 of the person receiving the call. In this implementation, alist of signature file names may be stored in computer 90 so that acaller may browse the names of signature files stored in the device ofthe person receiving the call. Signature files may also be stored in acombination of both computer 90 and device 20.

In some embodiments, the signature information may not necessarily beuser-defined. For example, a list of pre-selected signature files maystored on computer 90 or a remote computer from which a user of device20 may choose. Such a list may be created by a wireless serviceprovider, an Internet provider, an Internet site, or a manufacturer ofthe wireless telephone.

With these implementations, the caller may simply select a signaturefile from the displayed list. The selected file is then sent along withthe call by computer 90 (if the selected signature file is stored incomputer 90) or associated with the incoming call at device 20 (if theselected signature file is stored in device 20). In some embodiments,the caller may be able to preview signatures before sending them. Forexample, computer 90 may send the selected signature file to the callerfor his or her review.

In systems that have a video capability, a video file containing a videoclip or frame may be sent instead of or in addition to the audio sample.This may be accomplished by selecting a video option from a signaturemenu and choosing a video file. In this case, the person receiving thecall is alerted by seeing or hearing the video clip and/or associatedaudio. It will be appreciated that a video clip may have its own audioportion associated with it so that the video clip (or frame) by itselfwould be sufficient to alert the person receiving the incoming call.

The above-described signature feature may be implemented in many ways.In some embodiments, for example, the audio or video signatures may bestored in (the caller's) device 20 and sent along with the outgoing callor page via link 33 and computer 90. In other embodiments, however, thesignature information may be stored in computer 90 and associated withthe outgoing call when it is processed by computer 90. This type ofembodiment may be implemented when it is desired to conserve memoryspace within device 20. In still other embodiments, signatureinformation may be stored in both device 20 and computer 90. In anycase, computer 90 may determine the format requirements of the devicereceiving the incoming call or page and convert the accompanyingsignature information into a suitable format.

Another implementation of a system in accordance with this invention mayuse an architecture 300, which is shown in FIG. 5. Using thisarrangement, programmer 30 (or similar circuitry) may be embedded withinprogrammable device 20. User-defined information may be provided todevice 20 from source 50 via link 32. Such information may be routed toprogrammer 30, which may perform some or all of the above-describedfunctions.

If source 50 is an acoustic source, however, link 32 may not be needed.For example, if a user desires to program an acoustic sound into device20, the user may place a transducer 25, (e.g., a speaker/microphoneexisting within or external to device 20) near the acoustic signalsource, place device 20 into an “acquisition mode,” and record an audiosample. In this case, transducer 25 coverts the acoustic signal into anelectrical signal, which is provided to programmer 30 for processing andpossibly storage within device 20. A visual, audio, or tactile outputmay be provided by device 20 to indicate a sample has been successfullyloaded. A user may employ transducer 25 to acquire and record, forexample, a verbal message or sound effect (e.g., laughter, crying,sneezing, etc.) for use as a signature file.

Other embodiments of the present invention may use the embeddedarchitecture of system 400 as shown in FIG. 6. Using this arrangement,user-defined information may be requested by device 20 via link 32 andcomputer 60. With this approach, a user may select information fromInternet 80 or a remote computer and perform any necessary formatconversion within device 20.

In addition to selecting user-defined information with programmer 30, auser may customize that information by performing various editingprocedures. For example, a user may find an audio track or video clipthat suits his or her taste. It may be desired, however, to utilize onlya portion of that track or clip. In this case, a user may edit or“sample” a portion of the information to obtain the desired segment. Forexample, a user may wish to sample a few bars of a popular song and sendit along as signature information when making a wireless telephone call.Such editing may be accomplished, for example, by using an applicationprogram with programmer 30 or by using known software with computer 60.Furthermore, once the user has edited a particular piece of information,he or she may be given the option to review the piece to ensure it isacceptable. When a user is satisfied with an edited segment, he or shemay save it and be given an opportunity to “name” that segment, so thatit may be readily identified later by a user of device 20.

It will be appreciated that various other types of editing proceduresare also possible. For example, a user may combine and/or titter editthe content of segments of information. This may be accomplished using“cut and paste” routines in an application program. Other types ofrevisions may include modifying the color or content of a portion ofvideo clip or frame, as well as editing the audio track that accompaniesa video clip or frame. It may also include revising or combining audiosegments or creating customized audio segments to accompany video clipsor frames.

In some instances, a user may wish to download large portions ofcopyrighted audio or video. To prevent improper usage of such material,programmer 30 may include copyright protection software such as softwarethat conforms with the Secure Digital Music Initiative (SDMI). Generallyspeaking, this may allow an owner of such material to “check out” afinite number of copies so that unauthorized distribution is prevented.

A schematic diagram of a portion of a wireless telephone 500 that canreceive and play user-defined audio and/or video is shown in FIG. 7. Asillustrated in FIG. 7, telephone 500 may include antenna 510,receiver/transmitter (R/T) circuit 520, processor 530, communicationsinterface 532, speaker/transducer 540, alerting circuit 550, andoptionally, programmer 30 (or similar circuitry).

A user may program information into telephone 500 in several ways. Forexample, a user may connect telephone 500 to an external programmer 30(not shown in FIG. 7) via link 32 to program user-defined audio or videoin telephone 500 as described above. Processor 530 may route thisinformation to alerting circuit 550 for storage and subsequent use.Afterwards, the user may configure telephone 500 to play a certainuser-defined audio file stored in alerting circuit 550 when receiving anincoming call. Thus, when a call is received, processor 530 may instructalerting circuit 550 to play the selected file through speaker 540. If avideo file is chosen, processor 530 may instruct alerting circuit 550 toplay the user-selected video file through a display screen on thetelephone (not shown). Alerting circuit 550 may include programmablememory circuitry for storing user-defined information and drivercircuitry (not shown) for driving speaker 540 and/or a display screen ontelephone 500. Telephone 500 may also receive user-defined informationfrom communications network 95 via link 33 and antenna 510. With thisimplementation, user defined information, such as a signature file, maybe received by antenna 510 and demodulated with R/T circuit 520.Processor 530 may then route the demodulated signals to an appropriatelocation. In the case of a signature file, for example, processor 530may check the format of the incoming file to ensure it is compatiblewith the format required by alerting circuit 550. If the format iscompatible, the incoming file may be routed to alerting 550 for storageand subsequent use or to speaker 540 for immediate playing. If theformat is not compatible, the incoming file may be routed to programmer30 for conversion. After conversion is complete, processor 530 mayinstruct programmer 30 to route the converted file to speaker 540 oralerting circuit 550. If a video file was sent as a signature file,processor 530 may instruct alerting circuit 550 to play theuser-selected video file through a display in telephone 500 (not shown).In some embodiments, speaker 540 may be an enhanced performance speaker(as compared to those currently installed in telephones) with a capacityfor generating a full range of audio sounds. Moreover, it will beunderstood that circuitry similar to that shown in FIG. 7 may beinstalled for use in other communication devices such as PDA's, pagers,notebook computers, etc.

Some of the steps involved in programming user-defined information intoprogrammable device 20 as described herein are illustrated in the flowchart of FIGS. 8-9. It will be understood that although programmer 30 isused in the following description, computer/programmer 90 may alsoperform some or all of these (or similar) steps.

At step 100 in FIG. 8, programmer 30 allows the user to browseinformation for potential programming into device 20. As mentionedabove, this may include browsing audio/video information on theInternet, or on a hard, floppy, or optical disc drive of a computer. Atstep 102, the user may choose certain files for programming into device20. Next, at step 104, programmer 30 may determine the formatrequirements of device 20 and compare the format of the selected filesto that specified by device 20. This may be accomplished, for example,by electronically polling device 20. At step 105, if the formats arecompatible, programmer 30 may go directly to step 108. If the formatsare not compatible, at step 106, programmer 30 may convert the selectedfiles to a format compatible with device 20. In some embodiments, theuser may be prompted to confirm that the conversion should be performed.In addition, programmer 30 may also prompt the user to supply a name forthe converted file. Moreover, if the selected file cannot be converted,programmer 30 may so inform the user.

Next, programmer 30 provides the user with an option of editing thecontents of the resulting files at step 108. If desired, the user mayfirst review the converted file to determine if editing is warranted. Atstep 109, if the user chooses not to edit the file, programmer 30 may godirectly to step 112 (shown in FIG. 9). If the user decides to edit thefile, he or she may do so at step 110. When finished editing, the usermay be a given the option of reviewing the file at step 111 by returningto step 108 to determine whether the file is acceptable or requiresfurther revision. Programmer 30 may alternate between steps 108-110until the user is satisfied with the resulting file. When editing iscomplete, programmer 30 provides the user with the option of programmingthe file into device 20 at step 112. At this point, (step 113) the usermay exit the program at step 114 or return to step 100 to browse moreinformation.

It will be understood that these steps are merely illustrative, and arenot meant to be comprehensive or necessarily performed in the ordershown. For example, it may be desired to edit a file already stored indevice 20. In this case, a user may bypass steps 100-106 and go directlyto step 108. In some embodiments, selected files may be revised beforeconverting them to format compatible with device 20. This may bedesirable when the file's original format facilitates the editingprocess. In addition, programmer 30 may determine the formatrequirements of device 20 at any time before the conversion occurs. Auser may also name or revise the name of a selected file at any time.

Some of the steps involved in sending signature files to programmabledevice 20 as described herein are illustrated in the flow chart of FIGS.10-12.

At step 150 in FIG. 10, device 20 allows the user to browse signaturefiles for potential transmission to device 20 of the person receivingthe call (hereinafter the “receiver”). At step 150, the user may beprovided with option of creating a new signature file if a suitablesignature file not found on the list. At step 154 the user may select asignature file. Once a signature file is selected, computer 90, at step156, may determine the location of the selected signature file. Suchlocations may include, but are not limited to, the caller's device 20,the receiver's device 20, or computer 90.

If computer 90 determines that the signature file is located in theuser's device 20 (i.e. the caller's device 20) computer 90 may retrievethat file from the user's device 20 at step 158. Next, computer 90 maycompare the format requirements of the receiver's device 20 with theformat of the retrieved file to determine if they are compatible at step160. If the formats are compatible, computer 90 may go directly to step164. If the formats are not compatible, computer 90 may convert thesignature file to an acceptable format at step 162. At step 164, thesignature file may be sent along with, or somewhat before, the outgoingcall. At step 166, the receiver's device 20 may replace its ringsequence with the signature file and play the signature file. At step167, the receiver's ring sequence may be returned to its originalsetting and the program may exit.

If, however, the signature file is located in computer 90 (step 156),computer 90 may retrieve that file at step 168 (FIG. 11). Next, computer90 may compare the format requirements of the receiver's device 20 withthe format of the retrieved file to determine if they are compatible atstep 170. If the formats are compatible, computer 90 may go directly tostep 174. If the formats are not compatible, computer 90 may convert thesignature file to an acceptable format at step 172. At step 174, thesignature file may be sent along with, or somewhat before, the outgoingcall. At step 176, the receiver's device 20 may replace its ringsequence with the signature file and play the signature file. At step177 the receiver's ring sequence may return to its original setting andthe program may exit.

On the other hand, if computer 90 determines at step 156 that thesignature file is located in the receiver's device 20, computer 90 maytransmit an indicia indicative of the selected file to the receiversdevice 20 along with the outgoing call at step 178 (FIG. 12). Next, thereceiver's device 20 may associate a signature file that corresponds tothe indicia, replace its ring sequence with that signature file, andplay that signature file at step 180. At step 182, the receiver's ringsequence may be returned to its original setting and the program mayexit. It is assumed for the purposes of this illustration thatsignatures files stored in the receiver's device 20 are already in asuitable format. However, if this is not the case, a conversion step maybe added between step 178 and step 180 (not shown).

It will be understood that these steps are merely illustrative, and arenot meant to be comprehensive or necessarily performed in the ordershown. For example, computer 90 may determine the format requirements ofdevice 20 at any time before the conversion occurs.

Thus, it is seen that a device for programming user-defined informationinto an electronic device is provided. The programmer allows a user toprogram customized information, such as audio, video, or Internet accessinformation into his or programmable device. This allows a user to,among other things, customize his or her device to suit the user'sparticular taste. It will be understood that the foregoing is onlyillustrative of the principles of the invention, and that variousmodifications can be made by those skilled in the art without departingfrom the scope and spirit of the invention. For example, it is notnecessary that programmable memory within device be a fixed programmablememory. That is, a removable memory module may be programmed externallyfrom a given programmable device and subsequently installed in thatdevice. Furthermore, the many aspects of the invention are suitable foruse with hard-wired, cordless, or wireless communications devices. Forexample, user-defined audio and video and signature files may be usedwith hard-wired or cordless telephone systems. Accordingly, suchembodiments will be recognized as within the scope of the presentinvention.

Persons skilled in the art will appreciate that the present inventioncan be practiced by other than the described embodiments, which arepresented for purposes of illustration rather than of limitation, andthe present invention is limited only by the claims which follow.

What is claimed is:
 1. A method of providing an audio file to acommunications device, the method comprising: providing to a browser ofa communications device, a listing of multiple audio files, wherein atleast one of the audio files in the listing of multiple audio files isavailable in two or more different digital formats; receiving anelectronic request from the communications device that identifies afirst audio file that is available in the two or more different digitalformats; automatically identifying with computer hardware comprising oneor more computer processors, at least one digital format that iscompatible with the communications device; comparing the digital formatthat is compatible with the communications device with the two or moredifferent digital formats of the first audio file to identify at least afirst compatible digital format; and transferring to the communicationsdevice, at least the first compatible digital format of the first audiofile.
 2. The method of claim 1 wherein automatically identifying the atleast one digital format that is compatible with the communicationsdevice is transparent to a user of the communications device.
 3. Themethod of claim 1 wherein automatically identifying the at least onedigital format that is compatible with the communications devicecomprises polling the communications device to automatically identifythe first compatible digital format.
 4. The method of claim 1 whereinthe communications device is a wireless communications device.
 5. Themethod of claim 1 wherein the first compatible digital format of thefirst audio file is at least one of the group consisting of: MusicInstrument Digital Interface (MIDI), Motion Pictures Expert Group(MPEG), MPEG 2 layer 3 (MP3), Waveform audio file (WAV), Pulse CodeModulated (PCM), Windows Media Audio code (WMA), or Adaptive TransformAcoustic Coding (ATRAC).
 6. The method of claim 1 further comprisingallowing the user to search for the first audio file with the browser.7. The method of claim 1 wherein the browser is an internet browser. 8.The method of claim 1 wherein the browser is a Wireless ApplicationProtocol (WAP) compliant browser.
 9. The method of claim 1 wherein thefirst audio file is configured to be used as an indicia of an incomingcommunication.
 10. A system that provides an audio file to acommunications device, the system comprising: one or more computerprocessors configured to provide to a browser of a communicationsdevice, a listing of multiple audio files, wherein at least one of theaudio files in the listing of the multiple audio files is available intwo or more different digital formats; one or more computer processorsconfigured to receive an electronic request from the communicationsdevice that identifies a first audio file that is available in the twoor more different digital formats; one or more computer processorsconfigured to automatically identify at least one digital format that iscompatible with the communications device; one or more computerprocessors configured to compare the digital format that is compatiblewith the communications device with the two or more different digitalformats of the first audio file to identify at least a first compatibledigital format; and one or more computer processors configured totransfer to the communications device, at least the first compatibledigital format of the first audio file.
 11. The system of claim 10wherein automatically identifying the at least one digital format thatis compatible with the communications device is transparent to a user ofthe communications device.
 12. The system of claim 10 whereinautomatically identifying the at least one digital format that iscompatible with the communications device comprises polling thecommunications device.
 13. The system of claim 10 wherein thecommunications device is a wireless communications device.
 14. Thesystem of claim 10 wherein the digital format of the first audio file isat least one of the group consisting of: Music Instrument DigitalInterface (MIDI), Motion Pictures Expert Group (MPEG), MPEG 2 layer 3(MP3), Waveform audio file (WAV), Pulse Code Modulated (PCM), WindowsMedia Audio code (WMA), or Adaptive Transform Acoustic Coding (ATRAC).15. The System of claim 10 wherein one or more computer processors areconfigured to allow the user to search for the first audio file with thebrowser.
 16. The system of claim 10 wherein the browser is an internetbrowser.
 17. The system of claim 10 wherein the browser is a WirelessApplication Protocol (WAP) compliant browser.
 18. The system of claim 10wherein the first audio file is configured for use as an indicia of anincoming communication.